By way of background concerning the state of the modern graphics pipeline, a graphics subsystem generally cooperates with a host computer to perform certain specialized tasks on its behalf, e.g., tasks that require, relatively speaking, a lot of raw computational power such as preparing the output of an application for display on a monitor, or printer, or other device. To create a 3-D computer graphical representation, for instance, objects to be depicted are represented as mathematical models within the computer, which are well suited for mathematically intensive processing by the graphics processing unit (GPU) of the graphics subsystem. For instance, 3-D models can be made up of geometric points within a coordinate system consisting of an x, y and z axis, for example, corresponding to width, height, and depth, respectively. Objects are defined by a series of points, called vertices. The location of a point, or vertex, is defined by its x, y and z coordinates (or other coordinate system). In graphics terminology, one vertex is a point, two vertices define a line, or a line segment, and three vertices define a triangle where all three are “primitives.” When three or more of these points are connected, a polygon is formed, with the triangle being the simplest polygon, which can be used to approximate the 3-D geometry of an object and apply graphics data to the 3-D geometry to create a variety of artistic and realistic effects and color transformations. The graphics pipeline, using its various computational subunits, can process vertices and other streams of data very fast and efficiently to ultimately represent very complex 3-D objects in 2-D display space.
Thus, certain tasks, such as rendering and displaying three dimensional (3-D) graphics on screen, typically involve many calculations and computations that are well suited to be carried out by a graphics subsystem. In a simple graphics system, such computations occur according to some level of cooperative or shared processing by the central processing unit (CPU) and the graphics processing unit (GPU). In an exemplary scenario, after instructions are processed and some initial computations occur in the CPU, a set of coordinate points or vertices that define the object to be rendered are stored in video memory for further processing by the GPU in the graphics pipeline. If the data is 3-D graphics data, for instance, a tessellator may break the graphics data down into simple polygons according to predetermined algorithms designed to efficiently cover the surface of the object being represented—a process known as tessellation. Currently, in most graphics pipelines, the data may then be operated upon by one or more computational subunits of a GPU, such as procedural shaders, depending upon the instructions that are delivered to the GPU, which in cooperation with video memory, i.e., the frame buffer, processes the data according to the work instructions for the data, and outputs the data where appropriately directed, e.g., to a display or printer device.
As illustrated in FIG. 1, with respect to computing systems having graphics coprocessing systems, computing systems are divided between the host CPU and the graphics hardware. The CPU facilitates the making of calls to graphics APIs by applications and services requesting their use. Conventionally, the application and drivers are located on the CPU side and information from those sources is sent as work items to the graphics pipeline, such as displaying data on a monitor. First, the information is sent from the CPU to the GPU, as packaged by the CPU according to APIs. Then, the information from the application waits in memory until it is scheduled and processed by computational subunits of the GPU, such as the vertex shader(s) if 3-D graphics data is being processed. After the vertex shader(s) conclude their operations, the information is typically output from the vertex shader(s) through a special data path to the pixel shader(s) until it is accessed by the pixel shader(s) for further processing. After the pixel shader(s) have performed their operations, the information is placed in a frame buffer to be scanned out to a display, or sent back to the host for further operation.
The term “frame buffer” in today's graphics architectures generally refers to any memory (generally video memory included for interoperation with the GPU) used in connection with rasterization and/or digital to analog converter (DAC)-out processes. In this regard, though the term rasterization is sometimes used more generally, the processing performed in connection with pixel processing or setup engine processing in the graphics pipeline is generally referred to as rasterization. Scan-out or DAC-out, on the other hand, is the process of transmitting signals to a monitor or LCD based on the contents of the frame buffer.
Due to the specialization of the task and the computational resources implicated, graphics subsystems of computer systems are commonly used for displaying graphical objects on a display screen. The purpose of three dimensional (3-D) computer graphics is generally to create two-dimensional (2-D) images on a computer screen that realistically represent an object or objects in three dimensions. In the real world, objects occupy three dimensions having a real height, a real width and a real depth. A photograph is an example of a 2-D representation of a 3-D space. 3-D computer graphics are generally like a photograph in that they represent a 3-D world on the 2-D space of a computer screen, except the underlying image is generally modeled with 3-D geometry and surface textures.
Images created with 3-D computer graphics are used in a wide range of applications, from video entertainment games to aircraft flight simulators, to portray in a realistic manner an individual's view of a scene at a given point in time. Well-known examples of 3-D computer graphics include special effects in Hollywood films such as Terminator II, Jurassic Park, Toy Story and the like. One industry that has seen a particularly tremendous amount of growth in the last few years is the computer game industry and the current generation of computer games apply 3-D graphics techniques in an ever increasing fashion. At the same time, the speed of play is driven faster and faster. This combination has fueled a genuine need for rapid and flexible rendering of 3-D graphics in relatively inexpensive systems.
In accordance with these rapidly moving trend lines associated with graphics subsystems, however, compatibility, security and rights management have correspondingly evolved as issues. As each new generation of GPUs and associated hardware supplants the previous generation, in addition to the hardware, the interfaces to the pipeline (e.g., DirectX8, DirectX9, GDI, GDI+, etc.) have to evolve, and if they are expected to handle calls to “old” interfaces, then separate code need be written that ensures support for older hardware. After more than a few generations, the likelihood that the graphics interface code of any one particular operating system remains manageable decreases, and the likelihood for errors in handling due to incompatible function calls increases as the effects of compatibility code fan-out become rooted. An additional problem is that entirely separate “strains” of graphics interface code develop by virtue of the existence of different operating systems, or platforms (Macintosh, Linux, Windows, etc.), or even different strains included on the same platform (e.g., OpenGL, GDI+, DirectX, etc.). Thus, there remain problems whereby different versions of operating systems, graphics interfaces, and associated hardware may not all be co-supported, and these problems are becoming more complicated over time. It would be desirable to alleviate this problem without having to modify the core code provided with any particular operating system or set of interfaces.
With the same backdrop, the problems of security and content protection/digital rights management (DRM) are becoming more complicated to solve in connection with the graphics pipeline. With different operating systems, interfaces and hardware, there is no common mechanism that enforces data security or enforces protection of content/digital rights management conditions across all known pipelines. Thus, there is desired a common way or layer for addressing concerns over security of data and/or DRM that works independently of the graphics pipeline.
It would thus be desirable to virtualize the graphics pipeline of a computer system by providing a virtual machine as a layer of interaction of between the host processor and the GPU. It would be further desirable to implement systems and methods that overcome the shortcomings of present compatibility, security and content protection/DRM issues that are encountered when various versions of operating systems or interfaces or various architectures of GPUs are utilized.